The present invention relates to digital data communication systems, and is particularly directed to a new and improved management agent, that may be readily employed for simple network management protocol (SNMP), being distributed among individual channel units of a frame relay switching system, rather than in a proxy device interposed between the network and the channel units, with the address of an individual device being encoded in the community string portion of the SNMP packet.
Frame relay (FR) switching networks enjoy widespread success for supplying digital data servicesxe2x80x94principally in support of local area network (LAN) integration across wide area facilities. Frame relay derives its benefit by multiplexing xe2x80x98framesxe2x80x99 of data, or packetized data traffic, from each of a plurality of physical circuits into a common or shared backbone network, so as to reduce overall transport requirements, by creating more efficient use of the available transport bandwidth.
Prior to the advent of frame relay switching systems, LAN integration required the purchase of point-to-point digital data services delivered via individual physical circuits. Among the advantages frame relay provides over point-to-point services are enhanced network reliability and troubleshooting, through redundant and highly manageable switching networks, multiple end-to-end connections via permanent virtual circuits (PVCS) over single physical interfaces, and lower deployment costs that often result in lower consumer fees.
In a typical implementation, rather than being dispersed throughout the network, the switching backbone is confined to a very limited geographic area, requiring significant back-haul support. In addition, in stark contrast to the widespread availability of central office voice switches, the number of available data switches is relatively small. Also, due to the nature of physical interface design, a frame relay switch is often not necessarily employed in a manner that makes full use of its frame processing functionality. By accessing the frame relay switch through point-to-point facilities, both data transport time and idle time are presented to the switch interface. The frame relay switch then becomes limited at the point of its physical port access, often mandating the purchase and installation of additional frame relay switches and line cards.
In order to better utilize frame relay switch capability, as well as increase the utilization of back-haul transport bandwidth, it is desirable to efficiently extend frame multiplexing to central offices, remote terminals (RTs) and customer premises equipment (CPE) environments in a manner that address current deployment schemes. For this purpose, it has been proposed to implement frame relay switching networks in an architecture of the type diagrammatically shown in FIG. 1.
In this architecture, a plurality of frame relay channel units (or frameports) 11 terminate a large number of access lines 13 from associated CPEs 15, and are coupled to an aggregate data link 21 from the network 23. The aggregate data link customarily has a data transport capacity that is considerably less than the cumulative data capacity of all of the access lines 13. Included within this architecture is an outgoing data transport access mechanism that statistically multiplexes outgoing data from the various CPEs 15 into a single data stream for transport over the aggregate data link 21. The use of statistically multiplexing serves to reduce the back-hauling of circuits to the data switch, thereby more efficiently utilizing aggregate data transport resources, since the data is multiplexed at the point of access (the respective frame relay channel units 11), rather than at the switch.
In order to provide an orderly and efficient allocation of the limited bandwidth of the aggregate link 21 to each access line 13 requesting transmission service, yet without allowing any individual access line to tie up the aggregate data link 21 during periods of inactivity or congestion, the statistical multiplexing of data from the access lines 13 onto the aggregate data link 21 is based upon a prescribed opportunity-to-transmit arbitration mechanism, that is distributed among all users of the system, so that the state of the system is effectively shared with each access line.
In the above-referenced co-pending ""461 application, we describe a new and improved arbitration scheme, which calculates an arbitration value for each data line based upon a combination of parameters, including queuing delay and information customized for the particular configuration and traffic rate of that line. The calculated arbitration value is combined with a request to transmit or start bit and a physical location address code to produce a composite arbitration code, the respective bits of which are clocked onto a wire-ORed arbitration bus. As each channel unit""s arbitration code is clocked onto the arbitration bus, a respective channel unit will perform a bit-by-bit comparison with the state of the bus as driven by other channel units, to determine whether that channel unit is to be given priority to transmit. Whenever a channel unit sees a difference between its bit value and that on the bus, the channel unit knows it has a lower priority and terminates its participation in the arbitration cycle. As a result, at the end of the arbitration cycle, only the channel unit having the largest priority will not have dropped out, allowing it to take ownership of the aggregate data link.
In the incoming or receive direction (from the network to the channel units), the system typically employs some form of supervisory management entity 25, such as a Hewlett-Packard xe2x80x9cOpen Viewxe2x80x9d platform as a non-limiting example, which is connected to the network and manages the routing of data transmissions from the network to the individual channel units serving the end customers equipment, using an embedded in-band management scheme, such as industry standard SNMP, referenced above. Where the management scheme assigns an Internet protocol (IP) address per device, the overall management process becomes prohibitively complex and costly, as there can be literally thousands of IP addresses to allocate, assign and maintain.
An alternative approach, diagrammatically illustrated in FIG. 2, involves using a single, intermediary proxy device 30 as the management agent between the network manager and the data communication devices to be managed. This approach has the advantage that it allows a single supervisory device to manage a large number of data communication devices using a single IP address over a single access line. In addition, if the respective communication links 32 between the proxy agent device 30 and the managed devices employ a proprietary communication protocol, the managed devices can be made less expensive than would be the case if these devices were required to completely support SNMP protocol. However, the use of a proxy device has its shortcomings.
First of all, since the proxy device forms a junction of all incoming data packets from the network, a failure in the proxy device will result in a complete loss of management for all of the managed devices connected to it. Secondly, if a proprietary protocol is used between the proxy agent and the managed devices, the system becomes vendor-specific, rather than conforming with an industry standard, such as SNMP. Further, as new data communication devices are developed, the software within the proxy agent may have to be upgraded to allow it to be a proxy for the new devices, thereby adding to system complexity and cost.
In accordance with the present invention, the above-discussed shortcomings of conventional data routing management schemes are obviated by distributing the management agent among individual channel units of the system, without using any intermediate proxy device. Distributing the management agent is implemented by means of an address protocol employed by the management platform that encodes the (ASCII) community string portion of an SNMP packet to encode the address of an individual channel unit installed within a multi-device chassis or bank. In particular, each channel unit is programmed to discard any augmented community string message, that does not also include an associated xe2x80x9c.#xe2x80x9d appendix (where # is the physical location of the channel unit in the chassis), but to accept an augmented community string message, that also includes the associated xe2x80x9c.#xe2x80x9d appendix. Consequently, only the target channel unit will accept the SNMP message encoded with either of the prescribed community strings and the auxiliary xe2x80x9cdot-#xe2x80x9d appendix.
In a network architecture of the type described above, with reference to FIG. 1, since each of a plurality of data communication devices shares the same aggregate data link from the network, each channel unit will xe2x80x98seexe2x80x99 the same data traffic coming in from the network, and is continuously looking for an IP address within any incoming packet. Since the virtual circuit does not extend beyond the channel unit, all channel units within a common installation will assume that the IP address (data link circuit identifier) in the destination field is their identity.
To distribute the management agent across each of the channel units and distinguish among multiple devices, auxiliary device specific address information is embedded in the (ASCII) community string portion of the SNMP packet from the network to the channel units. Where the network-coupled management platform desires to specify a particular channel unit among a plurality of devices within a chassis, the community string is encoded by the management platform to include an auxiliary xe2x80x9cdot-channel unit numberxe2x80x9d appendix to a community string that otherwise will evoke a response from only a single xe2x80x98masterxe2x80x99 channel unit.
The master channel unit, such as that having the Ad lowest numbered installed location in the chassis, functions as an interrogatable chassis status information source, that can be accessed from the network-coupled management platform. The master channel unit may respond for the chassis with system parameters, to requests for occupation status of the chassis, and accept write messages to system level parameters. It then forwards that information to the other devices located in the same chassis.
To perform a read request to the master channel unit, a first prescribed community string (e.g.,xe2x80x9cpublicxe2x80x9d as a non-limiting example) is employed. In order to write a message to the master channel unit, a second community string (e.g., xe2x80x9cprivatexe2x80x9d as a non-limiting example) is employed. Unless a given channel unit sees a prescribed community string appendix associated with only that channel unit, the message is discarded. As a result, all channel units other than the master channel unit will discard any message containing one of the above community strings without the appendix. This readily allows only the master channel unit to respond to SNMP messages encoded with either of the prescribed community strings.
To communicate with a particular channel unit within the chassis, the supervisory management platform uses the same community string for accessing the master channel unit, plus an auxiliary appendix that identifies the card slot number of the target channel unit, which number specifies the physical location or slot within the chassis where the channel unit of interest has been installed. For a xe2x80x98readxe2x80x99 message, the community string is augmented as xe2x80x9cpublic.xxe2x80x9d, as a non-limiting example, where x is the chassis slot location (#) of the channel unit being addressed. For a xe2x80x98writexe2x80x99 message to the addressed channel unit #y, the community string is augmented as xe2x80x9cprivate.yxe2x80x9d, as a non-limiting example.
In accordance with the protocol of the distributed embedded in-band management scheme of the present invention, each channel unit, including the master channel unit, is programmed to discard any augmented community string message that does not also include its associated appendix, but to accept an augmented community string message, that also includes its associated appendix. Consequently, only the target channel unit will accept the SNMP message encoded with either of the prescribed community strings and the auxiliary xe2x80x9cdot-#xe2x80x9d appendix.